QRZ! Ham Radio 4

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / files / amiga / cdoc720j.lzh / readme.amiga < prev next >

Wrap

Text File | 1993-08-25 | 73.3 KB | 1,799 lines

C-BBS V7.20j (Multi-Port) for the AMIGA (Kickstart V1.3 and V2.04) VE5VA 28-Aug-1993 NOTE. Users of V6 or earlier C-BBS versions should be aware that in order to use V7.20 you must run a conversion program on your mail.dat file (whose format has changed) and there are 3 modifications required to config.mb before V7 can be used (see the notes.70 and notes.72 files). If you are currently using V7.00a then your mail.dat file has the correct format BUT there are two extra lines of information which must be added into the config.mb file and also a few extra parameters added to existing lines. If you are using V6 and upgrading to V7.20 you should start with the config.mb on the distribution disk and modify it to suit your local needs. As of V7.00b the Amiga C-BBS can now handle multiple serial ports and, because of this, the "sysop" program can now be used to send, read, kill mail and other functions as long as they don't require the serial port (e.g. it can't use the 'X' command). The multi-port code has been implemented in a way which means that users with only one port do not have to do anything to use the new program other than to copy the new executables. The multi-port functions are described in the separate documentation file "cbbs-multi.doc". An AREXX port has been added to the programs and SYSOP can send and receive AREXX commands. See the separate files "rexx.doc" and "fx.doc". Also see the #G option described below which allows you to tell C-BBS not to use AREXX. This program is basically a C-BBS 7.20 version of the W0RLI BBS. It was originally put together for the IBM-XT by K3RLI, AG3F and others. It is written in the 'C' programming language which made it fairly easy for me to port to the AMIGA because I have been using C since 1974. However, it has had to be modified somewhat to make it work on the AMIGA. Versions 6.1e and later have also had modifications added to make C-BBS talk to THEBOX (a BBS very common in Germany). V7.20 also adds the ability to use FBB forwarding. It has been used extensively on an AMIGA 3000 with the V1.3 and V2.04 Kickstarts. Both 'mb' and 'sysop' start up and appear to work OK with Kickstart V1.3 on an Amiga 1000 but have not been tested extensively. I have also used an IBM dual-serial card on my GoldenGate II bridgecard to run two copies of 'mb' and a 'sysop' together without any problems. A single copy of 'mb' should work on a system with 512K of memory but I have not tested this recently. I have run C-BBS on a single floppy drive, although that required limiting the number of files on the BBS. With such limited disk space you will only be able to handle transfer of mail rather than running as a full-blown BBS. But if you have a hard drive you can run a full-size BBS with this program. If you are already familiar with the C-BBS or W0RLI (or MBL) systems you should have little trouble getting this thing to go. You MUST be able to use the CLI and an editor in order to set the BBS up properly. I have only used the BBS with a KAM, a TINY-2 and an old TAPR TNC1 with the upgrade to TNC2 V1.1.6, but there should be no problem running this BBS with others, such as GLB, provided that they are TNC-2 compatible (if you are running one of these, read the info below about the problems with the TAPR V1.1.6 just in case they apply to you). The PK-232 and PK-88 presented some problems and there is a separate tnc.on.pk and tnc.off.pk file for them in the cbbs directory but I cannot guarantee that they will work properly for you as I only was able to test C-BBS with the PK-232 and PK-88 for a brief period. The program will permit KAM users to run one HF and one VHF port. It will only allow connects from one side at a time but forwarding and logins to HF and VHF can be accomplished. For other TNCs you are stuck with running either VHF or HF at any one time. I have not been able to modify the code so that it will handle multiple simultaneous connections and it looks like I never will. I have done very little to customize the program for the amiga ... no menus etc. There are two reasons for this. First, it's a lot of work and I don't feel like doing it. The source is here and compiles with MANX 5.2a, help yourself! Second, there are other C-BBS and W0RLI systems around which run on IBM and other disgusting machines. They all use the same command structure so if you can run the amiga BBS, you can run IBM etc.. But if the commands are all buried in menus, you won't be able to switch to other machines. Not a big deal but another justification for me to leave well alone. The only concession to the amiga environment was to provide a window title when the BBS comes up. Clicking on the top-left 'close' gadget will make the BBS shut itself down in the same way as the 'Q' command except that it does not ask you if you are sure you want to terminate the program. The two numbers in the title separated by a slash are the highest message number and the number of active messages. In earlier versions of C-BBS the number of active messages was exactly that, the number of messages you would see if you asked the BBS to list every mail message it had. But in V7 this number also includes the number of messages created and deleted since the last 'GM' command. The BBS creates a new mail header for each message or bulletin received even if it is rejected by C-BBS and these are also counted as a message even though they don't contain useful information. So if the number of messages listed is way less than the number in the title bar, it's time to do a 'GM' command to clean up. In V6.71i (and later versions) I have modified the title bar so that it also shows the callsign of the user or BBS who is currently connected. When the BBS attempts a forward it also shows the callsign of the BBS being called. In V7.20 I have also added some code so that the BBS will indicate whether C-BBS called the station shown in the title bar (e.g. >VE5BBS) or whether they called into C-BBS (<VE5BBS). The program also shows the port name after the program title. I have not explicitly modified the program to take advantage of available ram. But look at the tnc.on file. When the program starts, it dumps the tnc.on file into your TNC to initialize its parameters. It also allows you to put CLI commands in that same file and you can, for example, set up your config.mb file so that help.mb, info.mb, user.dat, mail.dat and other files are specified as being in a ram: directory. CLI commands must then be put into 'tnc.on' to actually copy the files into ram: as the program starts up. Thus, you don't need to load the files into ram: as a separate operation before the BBS starts up. Your forwarding files can also be modified so that after a regular forwarding operation or after the regular console 'forward', the system copies mail.dat and user.dat back to disk. Users of multi-port systems should not do this because there's no way to ensure that another port isn't writing to the mail.dat or user.mb files at the time another port tries to backup the files. The files help.mb, info.mb and states.mb are not modified by C-BBS so they do not have to be saved back to disk. If you do this, you will also have to modify tnc.off so that it saves the files when the bbs is shutdown. You should also be cautious that shutting the bbs down before the ram: files are saved could leave the bbs files in an indeterminate state. Putting the files in ram: really speeds up the operation of the bbs if you are only using floppy drives. It also significantly speeds up other operations such as untangling the mail file and user files (GM and GU commands). It is safest to specify that the backup files mail.bak and user.bak are still on disk. Just in case. IF YOU ALREADY HAVE V6.6 or V6.7 INSTALLED If you are currently using V6.6 or V6.7 then there are five changes for you to make (one of them a major one). Read the file notes.70 and make the changes it describes. If you are running a V7.0 version then read the file notes.72. If you are using a PK-232 or PK-88 then you'll also need to look at tnc.on.pk and tnc.off.pk and make them your tnc.on and tnc.off files if that is appropriate. Read the file readme-v7.20j to see a summary of the changes to C-BBS since V6. That should be all that is required to upgrade the program to V7.20j. FOR A NEW INSTALLATION OF C-BBS - READ THIS PROCEDURE. ** Make a few backups of this disk!!!!! ** Print out this readme file, the manual.bbs file and the config.mb file which is in the 'cbbs' directory. If you aren't familiar with BBS systems at all then read manual.bbs first very carefully. As you read through it, it will help to have the copy of the config.mb file with you. But remember as you read it that it was intended for users of IBM machines so some references to things like DESQVIEW, G8BPQ (ignore all of Ch. 8!) and windows etc. are irrelevant to you. (The IBM concept of window mentioned in the manual is not the same as an AMIGA window and should be ignored). You should then read through the rest of this file. ** If you are going to use only a floppy disk as the BBS then you will have to clean up the space on it, for example removing the source code archive. Further, if you have only one disk drive then you are going to have to change the disk so that it can be booted. I haven't tried that at all but it can be done. Make a few backups, and then you can delete vt100.doc, manual.bbs, the readme files, everything in the src directory if you don't want it online, and if there are commands in the c directory you won't use, then remove them too. ** The TNC MUST be wired up for HARDWARE HANDSHAKING. If your TNC is not currently wired for hardware handshaking then do it NOW. My KAM is wired as follows: KAM Pin AMIGA 2 2 3 3 4 4 5 5 7 7 6-8-20 (all jumpered together on AMIGA side only) I have also modified C-BBS so that it can handle a telephone modem and a null modem. See the files phone.doc and nulmdm.doc for details. DO NOT connect up any other pins. Some TNCs and the AMIGA have power supply voltages on some pins which could destroy your computer, TNC or both if they are connected. For example, on the AMIGA-3000, Pin 9 of the serial port has a +12V supply - DO NOT CONNECT this pin to your TNC unless you are certain that your TNC does not use it. ** Before you start up the BBS the TNC PARITY MUST be set to NONE (or SPACE). On my KAM, no parity is "PAR 4" (and space is "PAR 3"). Any other parity setting will not work. You can use the vt100 program on this disk to talk to the TNC to set the parity before you start up the BBS. When you use the Vt100 program make sure that it is using the same baudrate as your TNC or you'll just get garbage on your screen. (Thanks are due to Frank, DF3UM, who suffered through the parity problem and brought it to light for me). There is a nasty problem with TNC1s that have the TAPR V1.1.5/6 upgrade. The manual states that setting PAR to 0 or 2 means parity is set to none, but it actually forces the parity bit to a one all the time (i.e. 'mark' parity). The BBS expects parity to be forced to zero ('space' parity). To get around this you can specify the '-t' flag when you start up the BBS and the BBS software will strip the high order bit off every character that it receives from the TNC. However, this should not interfere with compressed FBB forwarding if you use it. If you have a PK-232 or a PK-88 read the comments in the tnc.on.pk file in the cbbs directory. ** Your TNC must have this command already set: users 1 (on the KAM 'users 1/1') so that the BBS will only permit one user at a time to connect to the BBS. The BBS does a 'conok off' whenever someone connects but it is safest to make sure that nobody else can get in. Your TNC should also have the command: autolf off This stops the TNC sending a line feed after a carriage return and is not essential, but it does make the screen output clearer. All of these commands can be put into the tnc.on file. ** It is safest not to use the 'runback' command when starting up C-BBS. If C-BBS is started up this way then it will definitely crash the AMIGA if you try to do a '!' command in C-BBS. The best thing to do is to start it with the 'run' command from the CLI. Or you can create a CLI execute file and put it in your s: directory. For example, the content of my s:cbbs file is: ; This script is now used with the multi-port version of 'mb'. ; Normally I start up port A and, if I want it, the 'sysop' process. ; See cbbs-multi.doc for a description of the mbuser.index file. if exists T:mbuser.index delete T:mbuser.index endif cd work:cbbs run locker waitport VE5VA-LOCK 20 ; I don't need the -z argument when running mb because it is set with the ; setenv command in my s:startup-sequence. ; Default to port A on startup run mb waitport CBBS-A 20 This starts up the locker process which MUST be running before you start up C-BBS. The locker process handles the locking between multiple copies of 'mb' on a multi-port system and also between 'mb' and 'sysop', so it must be there. When locker starts up, it creates a port with the name "VE5VALOCK" and the waitport command waits until it can find this port and then it terminates. The '20' tells it to terminate anyway after 20 seconds even if it can't find the port. Then the script runs mb. ** The manual refers to use of transparent mode. Although V7.20 uses transparent mode when it does compressed forwarding with an FBB system, I haven't tested out the system doing a normal connect when in compressed mode. Try it out, but it might not work properly yet. It definitely won't work if you have to turn off the 8th data bit with the '-t' flag. ** You MUST edit the configuration file config.mb. There are two places in it (obviously marked) where you must put your callsign and one where you must put your QTH. NOTE also that there is one place where a line generates the current time in a message that is being forwarded. In the supplied config.mb file the time is specified as being Zulu. The -z argument (mentioned below) specifies to C-BBS how to correct your local time to UTC and then the $J and $K strings are printed in UTC instead of local time. If you want to print out the time in your local timezone then omit the -z argument. The timezone is explained later in this manual. R:$J/$KZ $M@$O [$Q] ^ Change this if necessary. The structure of this disk corresponds to the config.mb file but you can change it if you wish. If you have a hard drive you will certainly want to have C-BBS use that instead of a floppy. You can also set up the config.mb file so that it will use two (or three) floppies instead of one (i.e. you can spread the BBS directories across two or more drives to spread out the load). Unfortunately, there is currently no mechanism for spreading mail messages across two or more floppy drives - they must all be in the one directory. I have changed the remote sysop password scheme in the amiga version. It is described later, but you should change the existing example password, which is at the end of the config.mb file, or replace it with one line containing a single zero if you don't want to permit remote sysop. You can use the "makepass" program to make a random password for you which you can then edit into the config.mb file. ** When the program starts up it looks for the file fwd.mb to define what it does for forwarding files. This file will have to be edited. I have left parts of my forwarding files here for you to look at as examples. As distributed, fwd.mb contains an indirect file reference to porta.fwd. This, in turn, contains just enough to forward to VE5BBS which is our local BBS on vhf. NOTE that there is a '|a' as part of the connection string. This is only required if you have a KAM to force the forwarding onto VHF. Similarly, there are a few files (20m.fwd etc.) that do forwarding on HF and have a '~a' in them. If you aren't running a KAM you must edit these out of the files as you'll only have one port to use anyway, in which case delete the two characters '|a' or '~a' as appropriate. Notice also that some of the TNC commands have a '/' in them. These are specific to the KAM since many of its commands apply to the HF and VHF ports. Such commands are specified as, for example, 'retry 10/5', which sets the retry parameter to 10 for HF and to 5 for VHF. Similarly, the command 'retry 10/' sets the HF retry to 10 but leaves the VHF retry as it is. You can make C-BBS use a forwarding file other than fwd.mb after the BBS comes up by using the 'YF filename' command. I often use 'YF 20m.fwd' to change from VHF-only forwarding to HF and VHF forwarding. The HF forwarding is here as an example ONLY. It won't work on the air for you unless KC0TA has entered you in his user file as a BBS. Note that the 20m.fwd file refers to several other files, and these sometimes refer onwards to yet others. The reason for this is to keep the forwarding info easy to manage (really!). Also, the file ve5op.via contains an example of passing traffic by connecting to an intermediate KA-NODE. Near the end of this documentation I have added a couple of examples of how to work out what should be in a forwarding file. ** When the program starts up, it looks for the file 'tnc.on', which need not exist but if it doesn't your TNC had better be configured properly. If you are going to use 'tnc.on', you MUST edit it to make it conform to your configuration. If you aren't going to use it, delete it. The tnc.on file can contain comment lines (lines beginning with #) which are ignored, and CLI commands (lines beginning with !). All other lines are assumed to be commands to the TNC and are sent out the serial port (to a TNC or a modem). The tnc.on file contained on this disk contains a lot of comments about what it can do. Some commands that could be in here are those to force on hardware handshaking and any other TNC parameters useful to the BBS. Even if you only use the TNC with the BBS (and therefore you never change the parameters) it can help to have them 'softwired' into this file 'just in case'. You could, for example, put EVERY command your TNC understands in here so that if the TNC ever gets scrambled, just restarting the BBS will restore the TNC's sanity. I have commented out those commands specific to the KAM. If you have a KAM, edit them back in by removing the comment symbol at the beginning of each TNC command line. For TAPR upgraded TNC1s and for PK-232 or PK-88 OR the MFJ-1270B and possibly other MFJ TNCs, you MUST have the two commands: newmode off nomode off in the tnc.on file because this is the ONLY combination of these two commands that will work properly. This is not exactly what the BBS needs but is as close as the TNC can get. It works fine for the BBS. The only place it might cause you problems is if you use the 'TA' command and connect to a station. On the disconnect the TNC stays in convers mode so you MUST remember to type '^C' (CTRL-C) to force the TNC back into command mode before you type '^E' to get back to the SYSOP prompt. In the KAM these commands are set to: newmode on nomode off For other TNCs these commands should be set to whatever will cause the TNC to return to command mode on a disconnect and to go to convers mode when a connection has been established. If your TNC won't do this then it is almost certain that the BBS won't work properly. ** For TAPR TNC1s and upgrades it is best to be sure of forcing the TNC into hardware handshake mode by specifying all of the following commands in the tnc.on file: start 0 stop 0 trflow off txflow off If you are using a phone line then the commands in tnc.on and tnc.off will usually be Hayes compatible AT commands and you must include the AT at the beginning of each command line. At a minimum, you must put "ATS0=2E0" in the file. ** When you terminate C-BBS, the last thing it does just before it closes the serial port and the window is to send the content of the file 'tnc.off' to the TNC if the file exists. The structure of this file is the same as for tnc.on and may also contain comments, CLI commands and/or TNC commands. You MUST edit this file to make it conform to your configuration or delete it if you don't want anything done at shutdown. If, for example, you have set up the bbs to keep user.dat and mail.dat in ram:, then this file should contain the commands necessary to write them back to disk before the program exits. You can also add TNC commands such as the 'btext' command with a text saying that the BBS is off the air. If you are using a phone line, then the software will reset register S0=0 to turn off automatic answering. ** The gateway commands have been removed from the original IBM version of the program and are not implemented in the Amiga version either. ** The A, AH, AI and C commands have all been removed from the 'mb' program but the 'sysop' program can now do the 'A' commands by sending the appropriate commands to other 'mb' processes using AREXX messages. If option #G is used to turn off AREXX then these commands won't work. ** A 'KL' command has been added for the sysop only. It kills a sequential list of messages but it will not kill traffic messages. For example: KL 103 117 will kill all non-traffic messages between message number 103 and 117 inclusive. The BBS asks if you are sure before proceeding. In V6.5 and later, the distributed IBM version added the ability to give up to four separate message numbers to be killed to the 'K' command. So you could give the command: K 5 198 435 897 and this will delete only message numbers 5, 198, 435, and 897. The KL command was added at the request of Frank DF3UM who has a hard drive and sometimes must kill a large number of sequential messages. ** The 'L' command has been modified to allow the user to search for titles that contain a specified substring. The user may add a quoted string to any 'L' command and the command is then modified to print those that also contain the string in their title. For example, LL 10 prints the last 10 messages, but: LL 10 "amiga" prints the last 10 messages that have the word "amiga" in the title. The quoted string may contain spaces if necessary. The sysop can also add the ';' modifier after a quoted string. For example, L@ amsat "microsat" ; will print any amsat bulletins that have the word "microsat" in their title and the BID and other information will also be printed. ** The documentation in manual.bbs does not explain the 'M' command adequately. The 'M' works exactly like the 'S' command except that it requires the name of a text file as the SECOND argument on the command line. This allows you to mail a text file to a user or to create a bulletin from a text file. For example: mb all ram:text @ amsat #10 will create a bulletin in the same way as the command 'sb all @ amsat #10' except that the text for the bulletin will be copied from the file 'ram:text'. The sysop should ensure that if creating a bulletin with this command that he(she) also specifies a BID for the bulletin or edits the new message (using the 'e' command) and specifies the BID there. If a bulletin is created using this command it will have Hold status and so you have to edit the bulletin to change the 'H' to 'N' to allow the BBS to forward it. ** A fake command '##' has been added which causes the BBS to disconnect as if a 'bye' command had been entered. The reason for this is that if C-BBS is connected to another BBS or user through a KA-NODE which sends '###DISCONNECTED' or '###RETRIED out', then C-BBS will simply disconnect instead of having to wait for the KA-NODES to force the disconnect. ** In previous versions of C-BBS, after it had finished responding to a reverse forward request, it would send the string "*** Done" to the other BBS. This apparently causes problems with some systems that don't understand this. So as of version V6.71j I have modified C-BBS so that it does not send "*** Done" but, instead, simply disconnects. Also I have modified C-BBS so that when it is forwarding to another BBS using the usual W0RLI protocol, the program will send only "<" as a prompt to speed things up slightly. ** The next SEVEN changes, described below, are optional. By default the system has these options turned ON and will use them. But the sysop can turn any of them OFF by including a command in the config.mb file. In any of the port description lines (i.e. for ports A, B ,C etc. or port Z) you can include a descriptor of the form #a where 'a' is a letter corresponding to the option you want to turn OFF. For example, my current port 'Z' descriptor line is: ZCE 300 10 600 100 10 0 27 8 0 If I wanted to turn options B and C off then I would include #B#C in this line: ZCE#B#C 300 10 600 100 10 0 27 8 0 ** OPTION #A. I have made a change to the way that this BBS handles bulletins which is NOT in the standard C-BBS. In order for this BBS to ACCEPT a bulletin from another system there MUST first exist a file in the msgs directory (Note that the name 'msgs' is specified in the config.mb file and can be changed if you wish). If for example you want to receive ALLUS bulletins then there MUST be an ALLUS.dis file in the msgs directory. If no such file exists then the program doesn't even check the BID, it just says "NO - Don't want it". This can save you from being inundated with bulletins you don't want from another BBS. This has happened to me, and with my limited disk space it doesn't take too many ALLUS bulletins before all my disk space is gone! Note that in order to FORWARD a bulletin to another system you must have a corresponding .dis file anyway, but my change requires the .dis file to ACCEPT a bulletin as well. The content of the .dis file is a list of the callsigns (one per line) of those systems that you will forward that type of bulletin to. It does not have to contain the name of the systems that you will accept the bulletin from. If you only receive bulletins and don't forward them, just put the name 'hold' in the .dis file, as is shown in the example .dis files on this disk. This option can be turned OFF by including #A in the port descriptor. If this is done then the BBS will accept any bulletin provided it doesn't already have it. ** OPTION #B. There is also a change to the way the BBS handles mail. If the BBS receives mail addressed to someone who is in the USER.DAT file then the BBS overrides the @BBS field in the message with the @BBS field from the user file. This will occur whether the message is one you typed in yourself or from a logged in user, or even in mail forwarded from another system. The assumption here is that if the user is in your user list then the @BBS field is more likely to be correct than any mail from outside. If the mail is addressed to a user who is not in the user file then the @BBS is not changed. I have found this option quite useful because users often type a send command such as 'S VE5DS' and they don't specify a home BBS even though VE5DS's home BBS is VE5BBS - not VE5VA. With this option the BBS will put in the home bbs if it has one. This option can be turned OFF by including #B in the port descriptor. In this case the @bbs field is not changed. ** OPTION #C. This has been changed from its meaning in previous versions. It used to control the number of lines between pause messages but now that C-BBS has the NP command this option is no longer needed. OPTION C is now used to turn OFF compression when forwarding to another FBB compatible system. The compression of any size of message now works correctly but I have retained the #C option so that if a user has problems with transparent mode, which is required for compressed forwarding, then they can still use the ASCII FBB forwarding. ** OPTION #D. When the BBS opens its window, by default it opens a window that has no borders, cannot be resized, and cannot be dragged around the screen. If you would prefer a window with borders, resizing and dragging, then put #D in the port descriptor. ** OPTION #E. Due to the great demand, I have implemented a way that a user can abort the output from C-BBS when they do a 'L' or 'R' command. If they type 'LL 100' this will produce a huge amount of output and the user may change his mind and want to abort the output. Up to now this couldn't be done other than by disconnecting. Now I have added some code that will abort the output to the user if C-BBS receives any data from the user. Thus, all the user has to do to abort the output is type a carriage return and wait for the TNC to empty its buffer. ** OPTION #F. Do not show titles in the window. ** OPTION #G. Do not use AREXX. This is useful for people who have older systems which did not come with AREXX or who have not bought it. ** Another change I have made (but not optional) is that if there are messages to ALL on your BBS and they are addressed TO your BBS (i.e. either the @BBS field is empty or it contains the callsign of your BBS), the beacon does not just say ALL as most other systems do. It also includes the highest message number addressed to ALL, e.g. ALL(489) to show that the highest message to ALL is numbered 489. This allows users to see when a new message to ALL has arrived at the BBS without them having to log in, they just monitor the beacon. ** The version 7 release of the states.mb file has changed from the V6 version. All calls that used to have .USA.NA on the end have had the .NA removed to save space in the file. This has caused me a problem with some of the local systems that don't like a hierarchical call that does not have the continent designator on the end (especially FBB). So I have added code into the chkhier() routine so that if it finds a callsign with .USA or .CAN, then it adds .NA to the end. If you make changes to states.mb the callsigns MUST be in upper case. ** I have added justification of text when the SYSOP types in a message. If you are near the end of a line and type a word that is longer than will fit, the BBS will move the whole word on to the next line. ** I have added an OP command which allows you to toggle options on or off, EXCEPT that once option #C is off you cannot toggle it back on again. For example, the command "OP D" will toggle option D. ** There are a few messages already in this BBS as distributed. They are a few bulletins which are really out of date now. You can delete them when the BBS first starts up. Do a 'll 10' command to list them and then use the 'K' command to kill them e.g. K 1 will kill message number 1 and so on. Or use the 'KL' command to kill them all with one command. Then do a 'GM' command to clean out the files. You must periodically execute the 'GM' command anyway to clean out old files. This can be done automatically or manually as described in manual.bbs. In C-BBS V6 a new feature was added such that deleted files can, if you wish, be archived instead of being deleted. If, for example, you want to archive AMSAT bulletins, then you must create a directory called AMSAT immediately under the C-BBS directory. Then instead of deleting amsat bulletins when they get old, the program will store them in the amsat directory. NOTE, I think it is dangerous to have a bulletin board directory name the same as a bulletin name. For example, if you store files about satellites in a directory called AMSAT, then the 'GM' command will archive AMSAT bulletins in there as well. The structure of archived mail is not the same as a regular text file and you will not want your users trying to download these files. ** This distributed version also has a few BBS file areas. You can add more or remove some as you wish. But remember to create corresponding directories for the new ones. The reason I have a specific write-only 'upload' directory while all others are read-only is that a user might upload a file containing arbitrary binary characters and then download this same file to themselves. It is possible that the bad characters in the file will mangle your TNC. Alternatively, a user might upload a file that contains obscenity or is commercial in nature and you would not want to be held responsible for distributing it any further. So to avoid this, users can upload a file into the specific area and then send you mail telling you that it is there. You can then move the file to its intended area after you are sure it is safe to do so. Thus, users can't write into the normal file areas and can't read from the upload area. ** The content of the file 'files/info.mb' is sent to any user who issues the 'I' command. It currently has a few lines in it briefly describing that this is the C-BBS program. If you want to, you can edit the file and add to it your name, qth and the type of TNC, rig etc. that you are using. ** The ! SYSOP command that allows you to execute CLI commands works except that the output of a CLI command goes to the window in which C-BBS was started, NOT to the C-BBS window itself. This is annoying but I can't find a way around it yet. On the other hand, this is a multitasking machine and you can always have a separate CLI window open to execute CLI commands anyway. So I'm not gonna bust a gut to sort it out. ** In my version of C-BBS the remote sysop password does NOT work as described in manual.bbs. I felt that the password mechanism used there is very weak and it wouldn't take a determined snooper very long to be able to break into your system remotely if remote sysops use it very often (NOTE that in order for someone to successfully be a remote sysop, you must first set that privilege for them in the user file AND set the 'R' privilege for port 'A' in the config.mb file AND set up a proper password as described below). Instead of using a line containing 64 characters, the new password scheme uses a line (or lines) containing up to 64 positive non-zero integers. If a remote user tries to get in, the system still sends them four numbers as a challenge, but instead of sending the corresponding letters of the password, the remote sysop must send the SUM of the corresponding numbers in the password. Since you can't easily fit 64 numbers on a line, you can put the numbers on several lines with all but the last line terminated with a backslash character. For example: 17 42 93 81 90 3 27 82 103 35 72 64 13\ 76 7 25\ 23 47 56 62 18 11 95 79 126 Using this example password, if a user tries to be a remote sysop and receives the challenge 10 21 7 16 then they must answer with 105 (the sum of the 10th, 21st, 7th, and 16th numbers in the list). There MUST be at least 20 numbers and no more than 64 in the list AND they must all be positive and non-zero or the remote sysop function will be disabled. Thus, if you don't want to permit the remote sysop function at all just put a single zero on this line. The numbers should all be different and in random order to strengthen the password scheme. The program cbbs/makepass can be used to create a new random password. Redirect the output from makepass into a file, edit it so that each line except the last ends with a backslash ('\') and then edit it into the config.mb file. ** In V6.1e and later versions, I added two things to the window title bar. If the sysop has mail (i.e. the sysop callsign appears in the Btext "Mail for:") then the text "You have mail" will appear in the title bar. Also, the name of the current forwarding file is shown on the right hand side of the window title bar. In V6.71i I added another feature to the title bar. At the extreme left it will show the call of the user or BBS who is currently connected to C-BBS. ** In V6.1e (and all later versions) I have also added modifications to make C-BBS talk to THEBOX which is a bbs system that is very common in Germany. THEBOX only accepts an 'S' command from users or other BBS but it then internally classifies each message into Personal, Bulletin, Control or $ (another kind of bulletin). When it forwards, it then generates the appropriate SP, SB, SC or S$ command. I have modified C-BBS so that when it receives 'S' commands from users or any BBS it processes them slightly differently. The changes are insignificant when talking to other C-BBS systems or to users. But when talking to a THEBOX system C-BBS will reject the 'SC' command and change 'S$' into 'SB'. THEBOX also generates a 'lifetime' field on bulletins which is indicated by '#nnn' as the LAST item on the 'S' command line. The 'nnn' indicates how many days the bulletin is to be kept before it can be deleted. I have modified the structure of the mail header to include an unsigned character which contains the lifetime of the bulletin. The 'S' command has been modified so that it will accept the #nnn lifetime field from anyone. The lifetime is now also used when the system determines whether a bulletin is stale. Any bulletin which is created from any source without a lifetime field will have the lifetime field set to the default bulletin lifetime field that is already in the C-BBS config.mb file. The description of this line in manual.bbs begins "Number of days old a bulletin is ....". C-BBS now checks for THEBOX when it receives either [DL5UY- .... -$] or [THEBOX- ... -$]. So, every bulletin no matter where it comes from has a lifetime field and if C-BBS detects that it is forwarding to THEBOX, then it will add the lifetime field on a bulletin. The lifetime field is now shown to the sysop if he edits a bulletin and the lifetime field can be modified if he wishes. One slight change has been made to the way C-BBS handles an 'S' command to make it conform to THEBOX. If the command itself is just 'S' (not 'SP', 'SB' etc.) and the message is being sent to a valid callsign then the message will be made a Personal one, otherwise the message will become a Bulletin. C-BBS used to leave the message type blank. ** The distributed version of IBM C-BBS can pick up mail from a user's KAM if the KAM is V3.0 (or later). KAM V3.0 will accept a reverse forward request and will send any outgoing mail from its user to any BBS that logs in and asks for a reverse forward. I have made one extra change when handling a KAM mailbox. The KAM only sends personal messages but the user could put in the KAM, for example, a command such as: S all @ allus The distributed version of C-BBS for the IBM will make this a personal message and also will Hold it for the SYSOP to check out. I have modified C-BBS so that it automatically changes this to a bulletin, creates a BID for it and does not put it on hold. NEW V7 Features and some previously undocumented ones The new C-BBS commands that came with the IBM version are documented in the manual.bbs file but I have made a few additions of my own: - When the sysop types the 'TA' command, C-BBS will send the TNC commands in the file 'talk.on' before starting the talk function. When the sysop types the ^E to return to sysop mode, C-BBS will send the TNC commands that are contained in the talk.off file. The structure of these files is the same as for the tnc.on and tnc.off files. The talk.on and talk.off files do not have to exist. - An undocumented feature that has been in C-BBS for some time now is the file "reject.btn". This file can be used to specify types of bulletins that you want your system to reject. For example, you may wish to receive ALLCAN bulletins except those that are sent to SALE or WANTED (i.e. SB SALE @ ALLCAN). The two lines: >sale @allcan >wanted @allcan in the file reject.btn will cause C-BBS to reject those bulletins @ALLCAN that are either to SALE or WANTED but it will accept all other ALLCAN bulletins provided you have the usual allcan.dis file. If a particular user is issuing bulletins that you don't want, then: <VE5VA in the reject.btn file will cause C-BBS to reject ANY bulletin from VE5VA. Similarly: >sale will cause rejection of ANY bulletin that is sent to SALE. Any combination of the three fields '<', '>' or '@' can be used. ***###*** OK .. Let's try it ***###*** You MUST first be connected to the directory that contains the mb program and the config.mb file, which on this disk is the 'cbbs' directory. This is because the config.mb file in this distributed version has all the directories specified as being relative to the 'cbbs' directory. You can change this as you see fit. Then execute a command of the form: mb [-bN] [-t] [-d] [-z[-]hh[:mm][D]] [-nNAME] [-uN] [-pP] [-wL/T/W/H] [config-file] The square brackets indicate that the arguments are all optional. You only need to set those which apply to you - and perhaps none of them will. You do NOT actually type the square brackets as part of a command. If the config-file is specified it MUST be last. All other arguments can be in any order. The default baudrate between the TNC and AMIGA is 9600 baud. If you use any other speed then you MUST specify the -bN switch to tell the program what baudrate to use .. e.g. -b1200 (NOTE that there's no space between the b and the number!) The '-t' option (which can be specified before or after the '-bN' if it is also present) specifies that the BBS software must strip off the high order bit of every character received from the TNC. This allows the BBS to be used with TNCs that set the parity bit to a one when in 'no parity' mode, such as the TNC1 with the TAPR upgrade to TNC2 V1.1.5. The '-d' option sets a debugging flag in C-BBS. Depending upon what debugging statements I have currently written into the source code, this could make C-BBS generate a lot of extra debugging output that is of no use to you. Unless you intend to read and/or modify the source code this option is useless to you. Leave it alone. If your computer clock is set to your local time, instead of UTC, then there are two different ways to tell C-BBS how to change your LOCAL time into UTC. The first method is to use use the -z[-]hh[:mm][D] argument when you run C-BBS. The second is to use the setenv command in your s:startup-sequence file to set the environment variable TZCHU as follows: setenv TZCHU [-]hh[:mm][D] (you can also use the manx 'mset' command) In both cases the [] brackets indicate optional parts of the argument and are not part of the argument that you type. You can use either the -z argument or the TZCHU variable to set your timezone. If it is specified, the -z argument overrides TZCHU. TZCHU is more convenient to use because you can set it in your s:startup-sequence file and then forget it (I use TZCHU). This feature (-z or TZCHU) is ONLY used when creating the timestamp in the R: header that is added to your outgoing messages. The time given in the timezone specification should be your standard timezone value (i.e. your timezone during the winter) and its structure is as follows. If you are west of Greenwich this number is positive, if you are east of Greenwich it is negative. The ':mm' can be omitted but allows hams in places like Newfoundland to specify their correct timezone (-z3:30 or -z3:30D). If you are in a timezone that uses daylight savings time, then you must add the letter D on the end. This allows the program to correct for DST during the summer (but you must still remember to change your computer's local time in April and October). NOTE that the program uses the North American definition of the start and end of DST. DST starts on the first Sunday in April and ends on the last Sunday on October. Examples: - my timezone is always Central Standard Time (no DST) which is 6 hours behind UTC. Thus I use '-z6' or "setenv TZCHU 6". - Someone whose standard timezone is 2 hours ahead of Greenwich and uses daylight savings time in the summer would use '-z-2D'. (NOTE how the "minus two hours" is specified). - If you are in England then you would specify -z0D. If neither the -z argument nor the TZCHU variable are specified then the program assumes your clock is UTC and you do not use DST. The -nNAME argument is used to tell the serial port driver to open a device other than the default "serial.device". E.G. -nibmser.device The -uN argument is used to specify that the serial port driver should open unit N instead of the default unit zero. This and the -n argument allow the sysop to run C-BBS off one of the ports on a multi-serial card. The -pP argument is used in a multi-port environment. It specifies which port this copy of 'mb' is to use when reading the config.mb file and the forwarding files. e.g. -pC will tell it to use port C. In this case, 'mb' will only read the information for ports C and Z in the config file and will ignore any other port definitions. This allows you to define all your ports in one config.mb file. The -wL/T/W/H argument allows you to specify the size of the C-BBS window when it opens. L and T and the position of the Left and Top of the window and W and H are the window's Width and Height - all in pixels. The program can be told to use a different config file than the default name of config.mb by specifying the name as the config-file argument. It takes a few seconds of disk churning to load the program but then the first thing that should happen is that it opens a new window for the BBS and the title should appear. It then prints a line containing the words Window and Port .. ignore this. It first sends an XON, followed by a Control-C, an 'X', followed by a carriage return. These will wake up a TNC if it has been XOFF'd and the Control-C X will force a KAM into packet mode if it was being used for RTYY, AMTOR etc. Then it tries to send three commands to the TNC: 'm off', 'cono off' and 'echo off'. If you have forgotten to connect the TNC to the amiga serial port or have set it to the wrong baud rate or wrong parity, then after about 30 seconds the program will timeout and exit because it can't get a reasonable response from the TNC. Connect it up properly and start again. It then sends out 'TXD' and looks for the 'TXD' reply from the TNC. This gets the program and TNC synchronized and allows the program to ignore any stuff in the TNC memory that it might have monitored while the BBS was off. The program then sends a PASS command to the TNC to find out what the pass character is. If it finds one it also sends a STREAMSW command to the TNC to find out what the stream switch character(s) is(are). On the KAM there are two, one for VHF and one for HF. Some TNCs do not use "STREAMSW" as the command. For example, the PK-88 uses 'CHSWITCH'. Don't worry about it, because if C-BBS doesn't get a reasonable answer from the TNC then it doesn't use a streamswitch character - and since the TNC only has VHF it doesn't matter. The program then prints the results of what it found. If you have included CLI commands at the front of the tnc.on file then the process may pause a bit here, especially if you include commands in tnc.on that load some of the bbs files from a floppy disk into ram:. The program should then show some data from the TNC as it dumps the tnc.on file into the TNC. It then prints out how many calls are in the calls.mb file (initially zero) and you can ignore it when it reports that the file is full. It then should print a line saying how many users are in the USERS.MB file. First time through it should say zero. (You had better have set your call in config.mb already because the program automatically adds you to the user file as a sysop, of course). It then prints out how much free chip and fast memory it can find and it will report that it is going to use 16K or 14K - ignore it. The program now prints out your local timezone setting or a message indicating that the timezone wasn't set. If it adds another line afterwards specifying the daylight savings time, then DST is currently in effect. It then prints: BT mail for: and after a couple more lines it should just go quiet. It is now waiting for someone to call into it or for you to wake it up as SYSOP from the keyboard. As SYSOP you type a Control-E character (default in config.mb and can be changed) at which point it should send the commands 'm off' and 'conok off' to the TNC. It then grinds the disk a second or so and then it should print the sysop prompt which the distributed config.mb file has set to 'SYSOP>' (if you plan to use AREXX with SYSOP do not change it). From there on you can issue the commands described in manual.bbs. As an example, just type the command DU at the prompt. It should display just your callsign first time through because you are the only user it has seen so far. A useful exercise at this point is to use the 'EU' command to edit your entry to add your name. As users log in and give the BBS their name and zipcode, the file will begin to grow. You can add new users yourself if you wish by using the EU command with their callsign. E.g. to add me: eu ve5va and then set the other parameters (such as name, zipcode etc.) as shown in the manual.bbs file. Another command to try is: LL 10 which asks the BBS to list the 10 most recent messages in the mail file. One thing you must keep an eye on, especially if you are only using floppy disks, is that if you have allowed logging of events (in config.mb) the log file, files/log.mb, will grow without bound as the BBS is used. So you must occasionally delete this file. If you are required by law to keep a record, print the file out or archive it on another disk and then delete it from the bbs disk. Try out the 'files/prtlog' program which prints a summary of the file. There is a problem with the prtlog program though. It can only be run on no more than one calendar month's worth of data at a time. To exit from sysop mode just type the 'B' command. It will then wait for a user to call in. The safest way to terminate the program is by clicking the close program gadget in the window title bar or use the Q command on the keyboard. This is so that the program will update the user and the mail files properly. Just removing the disks might leave them in an indeterminate state whether or not you have stored them in ram:. Also, if you have CLI commands in the tnc.off file to do some tidying up, the only way they can be executed is to quit properly. If disaster strikes and you lose the mail.mb file then it can be recovered as long as you still have the individual mail files in the msgs directory. Running the 'cbbs/msgs/mbrestm' program will recover the mail.mb file for you. Here are a few pointers, based on experience. ** If the BBS opens the window but then closes it and generates the "Timeout - .." message it can be for one of the reasons listed or others I haven't thought of or run into yet. Make sure that the TNC is plugged into the serial port. Also make sure that the cable is wired up properly. If neither of those help then try running the BBS with the "-t" argument to tell it to ignore parity. ** If you call another BBS but it won't accept mail from you, or it won't send you the [BBS-TYPE-CODES$] message, then you must log into that BBS as a normal user and send mail to the SYSOP asking him/her to set you up as a BBS in their user file. It also helps to have them specify that you are an expert user (although you can do that yourself) because this usually reduces the size of the login message. ** If your BBS won't forward bulletins make sure that you have a proper .dis file for the bulletin in the msgs directory and that the .dis file contains a proper list of callsigns. ** If your BBS won't accept bulletins from another BBS (i.e. your BBS says 'No - Don't want it') then you do not have a .dis file for that bulletin type or it has been rejected because of an entry in the reject.btn file. There must be a .dis file for that bulletin type even if you don't forward the bulletins to anyone else. NOTE that the bulletin type is the @ field of the bulletin. ** If your BBS won't forward mail for a user then either that user is not listed in your forwarding file for their BBS or their user record does not specify the correct Home bbs. If you list the message, you will almost certainly find that the @BBS field is blank. You can edit the message header (E command) and set the correct BBS. Some Forwarding Examples The best way to work out a forwarding file is to log in manually to the system that you are trying to forward to and record everything that occurs. Then work out the forward file from that. First, a simple example. I wish to forward to VE5OP who is here in Saskatoon. If I connect to VE5OP manually I see this (with my comments added on the right): c ve5op [ I type this command cmd:*** CONNECTED to VE5OP [ and the TNC says I'm connected [CBBS-6.0-H$] [ Here's the BBS login message EU> [ from VE5OP and its prompt. Now let's add the corresponding forwarding commands on the right hand side. c ve5op [ CC VE5OP cmd:*** CONNECTED to VE5OP [ <NOTHING HERE [CBBS-6.0-H$] [ HA0023C VE5OP EU> [ The 'CC' command not only sends the first connect message, but it also looks for the '*** CONNECTED' message from the TNC. So you must NOT use the 'R' command to read the '*** CONN' message. Remember that once you get to the [BBS-TYPE-CODES$] message you are in to the BBS and now you just use an 'F', 'H' or whatever list and you simply add in the list of calls whose mail is forwarded to VE5OP. So the complete script could look like this: CC VE5OP HA0023C VE5OP ve5op [ you can put lots more calls ve5pf [ in here as well as ntssk [ nts codes 97* [ or wildcarded zip codes *** EOF KAM users should remember to add the streamswitch characters into the initial connect command (e.g. 'C|aC ve5op' for VHF). If I had to go through the VE5USR digipeater to get to VE5OP, the only change in the script would be: CC ve5op via ve5usr because the digipeater would not generate any more text during the connection. A more complex example is if I want to connect to the VE5AGA BBS in Regina, which is 165 miles from Saskatoon. I have to go through two KA-NODES (VE5BAR and VE5ABO) and one digipeater (VE5GF) to get to VE5AGA. The path is in this order: VE5VA <-> VE5BAR-3 <-> VE5ABO-3 <-> VE5GF <-> VE5AGA bbs ka-node ka-node digi bbs Here's what I would see if I logged in manually with my comments on the right hand side: cmd:c ve5bar-3 [ I send the connect cmd:*** CONNECTED to VE5BAR-3 [ and my TNC responds. ###CONNECTED TO NODE VE5BAR-3(VE5BAR) CHANNEL A [ Now KA-NODE responds WELCOME TO SASKATOON...VE5OP LOCAL BBS... [ with its own messages ENTER COMMAND: B,C,J,N,X, or Help [ until it prints the ?c ve5abo-3 [ prompt without a CR. ###LINK MADE [ Connected to ABO ###CONNECTED TO NODE VE5ABO-3(VE5ABO) CHANNEL A [ and ABO now prints Welcome to the Ituna Node [ its own messages ENTER COMMAND: B,C,J,N, or Help [ up to the prompt ?c ve5aga v ve5gf [ now connect via digi ###LINK MADE [ The KA-NODE says OK [MBL-5.12-C$] [ Now the BBS responds Welcome to the Regina BBS [ with all its own de Perry VE5AGA [ login messages [ which can be anything for latest information 'D INFO.TXT' [ up to the prompt VE5AGA> [ with '>' at the end. And here's the script with the corresponding forwarding commands. cmd:c ve5bar-3 [ CC VE5BAR-3 cmd:*** CONNECTED to VE5BAR-3 ###CONNECTED TO NODE VE5BAR-3(VE5BAR) CHANNEL A [ R###CONN WELCOME TO SASKATOON...VE5OP LOCAL BBS... [ R! ENTER COMMAND: B,C,J,N,X, or Help [ R! ?c ve5abo-3 [ SC VE5ABO-3 ###LINK MADE [ R###LINK ###CONNECTED TO NODE VE5ABO-3(VE5ABO) CHANNEL A [ R###CONN Welcome to the Ituna Node [ R! ENTER COMMAND: B,C,J,N, or Help [ R! ?c ve5aga v ve5gf [ SC VE5AGA VIA VE5GF ###LINK MADE [ R###LINK [MBL-5.12-C$] [ HA0023C VE5AGA Welcome to the Regina BBS de Perry VE5AGA for latest information 'D INFO.TXT' VE5AGA> Note that the '?' prompt from the KA-NODEs does not have a carriage return after it and so there is just a corresponding 'S' command here. The 'R' command must not be used here because it always looks for a line ending with a carriage return and the BBS will just hang and eventually timeout here if you use 'R'. IF the KA-NODE sent a prompt with a carriage return after it (i.e. '?<CR>' instead of just '?') then you would need a 'R' command to read the '?<CR>' and then an 'S' command to send the next command to the KA-NODE. You can easily tell the difference because if there's no <CR> then you will see: ?c ve5abo-3 [ only requires SC ve5abo-3 such that both the prompt and your next command are on the same line, whereas if there were also a CR there you would see: ? [ would require R! (or R?) c ve5abo-3 [ SC ve5abo-3 When you use the 'R' command you can specify some context expected on the line such as the 'R###LINK' I have used here. It is useful to do this rather than 'R!' for the 'LINK' or 'CONNECTED' messages because if the link fails then the ka-node will send a message such as '###RETRIED OUT AT NODE VE5ABO-3'. This does not match the specified '###LINK' and so the 'R' command will fail and your BBS will disconnect the forward attempt. If you had specified 'R!' instead of 'R###LINK' then 'R!' will also accept '###RETRIED OUT' and then your script will hang until the process times out. However, you don't need to specify a context for all the lines so that some of them are just read with 'R!'. The 'R' command will search for its given string anywhere on the line so that you could check for '###LINK MADE' by specifying 'RMADE' as well as 'R###LINK' or 'R###LINK MADE'. Just how much context you give is up to you as long as it is sufficient to correctly distinguish the line from any other expected response. Note also that VE5AGA has a much longer login message than does VE5OP, but that doesn't matter. Once your BBS sees [BBS-TYPE-CODES$] it will look for the prompt with the '>' symbol in it and then start forwarding. If the VE5GF digipeater were between the ka-nodes rather than at the end, then the script would not be any more difficult. For example, if the order of the connections were: VE5VA <-> VE5BAR-3 <-> VE5GF <-> VE5ABO-3 <-> VE5AGA bbs ka-node digi ka-node bbs The connection process would then be: c ve5bar-3 c ve5abo-3 via ve5gf c ve5aga so the basic script would look like this (with some of the extraneous stuff removed): CC ve5bar-3 R###LINK etc. SC ve5abo-3 via ve5gf R###LINK etc SC ve5aga R###LINK HA0023..... etc. This procedure for working out a script can also be used for working through NET/ROM nodes and other types of networking or gatewaying nodes. NET/ROM connection scripts tend to be simpler than those using KA-NODES because you only need an "uplink" connect to get into the NET/ROM network, followed by a connect to the remote node, followed by a "downlink" connect to the BBS. For example, if I wish to connect to the VE5ND BBS using the SKSKTN and SKXTED nodes the script would be: CC SKSKTN [Connect to the first node. Do NOT need an R after this. SC SKXTED [Tell SKSKTN to connect us to SKXTED RConn [Look for the "Conn" part of the response SC VE5ND [Tell SKXTED to connect us to VE5ND RConn [Get the Conn message from the node. HA0023C ve5nd [ and now proceed with a normal script. etc. The BBS commands The BBS commands (as opposed to commands used for storing and forwarding mail) are easy to use. The primary use of these commands is to store information of local interest that you would not want to mail to everyone. Rather, you can store the information in a file area and let users read the information if they are interested. For example, on this BBS I have put a file area for QRP related information. Other file areas could be for AMSAT information, and another for a swap'n shop file. If someone is interested in QRP stuff but not in AMSAT info they can look through the QRP area and not have to read a lot of mail or bulletins that don't interest them. I'm going to use my local BBS VE5OP as an example here to show how the commands work. The first command to give to the BBS is the 'w' command which asks what are the major areas in the BBS. If I type 'w' on the VE5OP BBS I receive this info: Use W and directory ID: WA --> Amsat / Oscar WB --> General information WC ---> ARRL/ Newsletters WD --> Hamfests and Related EVENTS WE --> Packet Meetings-Minutes,ect. WF --> Packet LISTS WG --> Swap 'n Shop WH --> Local Users - Equipment WI --> NEW Uploads To Here Please If I want to see what is in the 'General information' area then I type the 'WB' command as shown beside the name of the area. The 'WB' command will print out: AA4RE 4k | Q.BAS 3k | README.R95 16k CONFIG.MB 4k | README.DOC 12k | WOOD1.INF 2k 41k of 31834k used, 27348k free. Now let's look at the AMSAT area by typing the 'WA' command: AO-13.SKD 2k | MIR.QSL 1k | O13.OCT 3k MIR.BCN 1k | MIR89.FEB 4k | O13.SEP 5k MIR.MAR 8k | MISC.021 2k | WEATHER.021 5k MIR.OPR 4k | O13-1.OCT 4k | WOOD1.INF 2k 41k of 31834k used, 27348k free. And also let's see what's in the swap'n shop area with the 'WG' command: 890416.SWP 7k | SWAP04.DEC 7k | SWAP20.FEB 7k 890523.SWP 7k | SWAP12.MAR 8k | SWAP29.JAN 6k SWAP0122.89 6k | SWAP2.NOV 8k | VE5BBL.SEL 1k 57k of 31834k used, 27348k free. Now, I decide that I want to look at what is in the file mir.qsl in the amsat area. To do this I must Download the file and tell the BBS which area it is in ('a') and it's name. So I type the command: da mir.qsl and receive the following info: ARRL BULLETIN 140 ARLB140 MIR SPACE STATION COSMONAUTS U1MIR AND U2MIR ARE NOW REPORTED TO BE OPERATING ON 145.400 MHZ. QSL CARDS SHOULD BE SENT VIA USSR, MOSCOW, 107207, P.O. BOX 679, B. STEPANOV. WA2ILB @ NN2Z> In this case the file contains an ARRL bulletin but it could be anything. If a user wants to send a file to the BBS then the file must be Uploaded into the 'I' area and a filename must be specified for it. For example: ui qrp.info The BBS will respond by telling the user to upload the file and then terminate it either with '^Z' or with '/ex'. The user should also send mail to the SYSOP to tell them that the file has been uploaded and what is in it. The 'W' commands can also by used by the sysop so you can try them on the distribution disk. But the SYSOP cannot use the upload and download commands. They mean something different when the SYSOP uses them. Summary of Changed Commands This section briefly summarizes the changes I have made to the standard C-BBS commands. - The A, AH, AI commands have been removed from 'mb' but will work from the 'sysop' process. - The user C commands have been removed. And the SYSOP 'C' command to set the clock has also been removed. This leaves only the sysop 'CM' command. - The L<, L> and L@ commands will now allow a wildcard in the callsign argument. - Any L command can have a quoted string appended to it to list those messages that contain the string in their title. - A KL command has been added for the sysop only. A command such as: KL 107 115 will Kill all messages numbered from 107 TO 115 inclusive. The command will NOT kill traffic messages. In the standard IBM V5 and later releases the 'K' command has also been modified from previous releases so that it will allow you to specify up to four message numbers to be killed by the one 'K' command. - The command '##' is treated the same as a disconnect so that if you are connected through one or more KA-NODEs which timeout or disconnect, C-BBS will initiate a disconnect from its end without having to wait for all the KA-NODES to disconnect first. - The user can abort a long output from an 'L' or 'R' command by typing a carriage return and then waiting for the TNC to empty its buffer. This function (as of V7) now works properly. - Several minor changes have been made to the 'S' command (and therefore to the 'M' command also). First, C-BBS will accept a lifetime specification as the very last item on the command line. Second, if a message type is not specified then if the message is addressed to a valid callsign then the message will be stored as a Personal one, otherwise it will be stored as a Bulletin. Good Luck. If you have problems getting C-BBS to work either because my instructions aren't clear or I've left out something important, please let me know. If you want help or have questions I'll be glad to help IF I can but you must take note of two things. - I will not answer mailed queries unless you also send me a proper SASE. U.S. hams PLEASE note that putting a U.S. stamp on your envelope won't do me any good. Canada Post expects me to use Canadian stamps. However, I will take a LOOSE U.S. stamp (40 cents) in exchange (NO IRCs please - I have plenty right now). If you send me a disk and expect it back, that will require correspondingly more stamps (about one dollar). - I have been ill since Sept 1984 with Chronic Fatigue Syndrome (Myalgic Encephalomyelitis to you Brits ... I'm one myself) and am always tired. As of this update to the documentation I still have it. I put this BBS together over many months (it took me six months to find a simple bug in my amiga code!) . So if I'm having a bad spell I may not get around to answering for a while. Be patient. Pete Hardie VE5VA 567 Delaronde Road, SASKATOON SASK S7J 4A7 CANADA or packet VE5VA @ VE5BBS.SK.CAN.NA or Internet (This is the best if you have access) hardie@herald.usask.ca or if that bounces try peter.hardie@usask.ca or USENET ...!alberta!herald!hardie If you phone me, please remember that the local time zone is Central Standard Time which is ALWAYS 6 hours behind UTC (i.e. 6 hours west of Greenwich). Please phone ONLY between the hours 2pm and 8pm CST (2000Z to 0200Z). I'm not giving my phone number here because I don't encourage it. There are a few hams who also can supply you with the latest version of C-BBS. If they are closer to you than I am then try them first. Frank Schmitt DF3UM@DB0IE Barlachstr 4, WD-6908 Wieslach GERMANY NOTE ... Frank was my first user and tester of C-BBS and did a lot to help me debug the early versions. But I have not heard from him since late 1992 and I have had no replies to my Email and letters for several months. Grisandi Giampaolo IW4CEA@IW4CEA Via Lago Di Garda 39 48100 Ravenna ITALY Crauwels Walter ON1AOT@ON6AR Heirbaan 31 2510 Mortsel BELGIUM Rene van Stipriaan PE1KBJ Dovenetelweg 94 NL-1508 CJ Zaandam HOLLAND Jason Burns G7HQA@GB7NEM.#12.GBR.EU 37 Gypsy Lane Marton-in-Cleveland Middlesbrough Cleveland ENGLAND TS7 8NF